0 comments
So, there is a parsing bug with the unique "+=", "-=", "*=", "/=", and "%=" PICO-8 flavored lua syntax. In normal lua, something like this:
b=odds[2]b=b-1 |
is valid syntax, treated as two separate expressions. That works in PICO-8, but this:
b=odds[2]b-=1 |
throws a syntax error. It's odd because this:
odds={1,3,5}b-=1 |
does not throw a syntax error. It seems to be only with the unique PICO-8 equals operators and directly after square brackets.
Fixing this could benefit people working on tweet carts as well as carts that are token & character/compression sensitive.
A game made by my middle school English students. Each class had 20 minutes to tell me what to make from scratch. There were 4 classes.
OS: Arch Linux
Browser: Chromium
The little pause/play button on the BBS player will pause and play the cart if you click it, but if you press the "enter" key on the dialogue to either continue or reset the cart, the pause/play button doesn't change (it should go back to the pause icon, but it remains as the play icon).
Here is a lil' cart to test it out real quick:
Operating System: Arch Linux.
In "config.txt" if
root_path ./ |
is set, then whenever you try to "cd" within PICO-8, you get a
cd failed |
error message. But if you change the root path to something other than "./", then PICO-8 works fine. It even works fine if you replace the "./" with a "../", which is a bit silly :D. It also works if you delete the "root_path" line.
Here is what the error message looks like:
:D.
EDIT: Ok, cd also doesn't work when you use the "-root_path ./" command-line parameter, but I guess that should have been common sense I guess.
Note: To see updates to this post, check out my blog here.
So I was working on making an improved version of "The Story of Zeldo" and realized a few weeks ago that outlining my sprites was taking up more CPU cycles than I wanted it to. I was using the outlining function where the palette is cleared to a color, then 8 sprites are drawn around the actual sprite to produce an outline effect as shown here. I decided to change all the sprites that needed outlines to 10x10 instead of 8x8.
|
[0x0] |
You can see the 10x10 sprites at the bottom right of the graphic. Getting rid of the outlining function like this improved my CPU, but wasted sprite space. I later needed more sprite space, but didn't want to take a CPU hit. Then I thought, what if I use rectangles to draw the outline of sprites instead of drawing actual sprites for the outline?
So that's what I did and I thought I would share. There are two parts to this process. The first is generating the rectangles for all your sprites and caching them at the beginning of the game.
-- 175 tokens
g_out_cache = {}
function init_out_cache(s_beg, s_end)
for sind=s_beg,s_end do
local bounds, is_bkgd = {}, function(x, y)
return mid(0,x,7) == x and sget(x+sind*8%128, y+flr(sind/16)*8) != 0
end
local calc_bound = function(x)
local top, bot
for i=0,7 do
top, bot = top or is_bkgd(x,i) and i-1, bot or is_bkgd(x,7-i) and 8-i
end
return {top=top or 10, bot=bot or 0}
end
g_out_cache[sind] = {}
for i=0xffff,8 do
-- prev, cur, next
local p, c, n = calc_bound(i-1), calc_bound(i), calc_bound(i+1)
local top, bot = min(min(p.top, c.top), n.top), max(max(p.bot, c.bot), n.bot)
if bot >= top then
add(g_out_cache[sind], {x1=i,y1=top,x2=i,y2=bot})
end
end
end
end |
init_out_cache should be called on startup in the _init function, passing in the start and end of the sprites you want outlined. Then the other part to outlining sprites is to actually outline them!
-- 84 tokens
function spr_out(sind, x, y, sw, sh, xf, yf, col)
local ox, x_mult, oy, y_mult = x, 1, y, 1
if xf then ox, x_mult = 7+x, 0xffff end
if yf then oy, y_mult = 7+y, 0xffff end
foreach(g_out_cache[sind], function(r)
rectfill(
ox+x_mult*r.x1,
oy+y_mult*r.y1,
ox+x_mult*r.x2,
oy+y_mult*r.y2,
col)
end)
spr(sind, x, y, sw, sh, xf, yf)
end |
This function just takes the rectangle data created from the init function and draws them as rectangles. A little bit extra logic is needed for xf and yf to work. Using these snippets, CPU efficiency of outlines is better than the old method, but worse than having no outline at all.
Although I thought this was cool, there are four at least four drawbacks to using this method:
- The token count is much higher than the old method (259 tokens instead of 59 tokens).
- The init function is not very efficient, because I went for token count on that instead of efficiency.
- Currently sw and sh are not implemented with this method. So it only works on 8x8 sprites.
- If a sprite is hollow, then the entire hollow region will be filled with the outline color as seen below.
|
[0x0] |
The green arrow is the old method, the red arrow is the new function.
Here is a demo of this sprite outline function in action!
As you can see, drawing 56 outlined sprites with this function saves over 15% of CPU usage compared with the old method!
As far as improvements go, here are a few areas this code could be improved on:
- There are only up to 10 rectangles drawn for each 8x8 sprite, but some sprites could have less rectangles if extra code is added to check for duplicate rectangles.
- Making variable sprite height and width, instead of just 8x8 (aka. sw and sh).
I am going to be using this in my Zeldo game in the future, but I will probably pre-process all the outlines I need and just store the rectangle data to save on token count. Comment if you have improvements for this, if you found this useful, or if you just have something to say. I might do another post like this in the future if I find people read this one :D.
This was supposed to be a game for the one hour game jam, but I made a song instead!
I really wanted to make a Pico-8 turing machine simulator. This is fully functional, with 1 tape. I want to allow the user to interact with the clipboard for ease of use. And this program will look prettier in the future.
If you have any input/ideas, feel free to comment!
Check it out on github!
A mouth wanting to eat a taco. The worst kind of torment.
A simple snow particle system, with rising ground. It doesn't eat the CPU completely :).
A space game I made with my friend Alex in 5 hours for a hackathon. You can use a laser, but it doesn't do anything. The topic for the contest was procedural generation, so the planets are procedurally generated (plus they have cool names).
YEAH!!!
PICO!!!
Merry Christmas Everyone!!!
Disclaimer, this game is about the true meaning of Christmas, Jesus! Enjoy :)
Pin The Nose. Christmas Edition!!!
Before playing this game, here are some questions you should ask yourself:
- Are you really bored?
- Do you need a stupid, but funny, teaching aid for some little kids?
- Do you like Santa Clause?
- Or Frosty?
- Or Rudolph?
For those who answered "yes" to any of the questions above:
This game is definitely for you! You will probably be playing this game for the
next 5 minutes. Later today, you might even show this game to your kids when
they come back from school, because it is so silly.
For those who answered "no" to all of the questions above:
This game is definitely not for you. In fact, this game would probably drive
you crazy. You shouldn't even press the play button.
Think of an annoying 12-year-old boy you may know. Now think of the video game
he plays for hours everyday. Now think about how much you hate that game. Now
imagine that the game you are about to play is just as bad or even worse.
That's right, worse. Please, save yourself from nightmares tonight and don't
play this game.
Thank you.
-- Alan Morgan
The base game engine is pretty much complete. Some of the things I plan to finish in the next week is:
- saving the level you got to and score
- having a scoring system
- pretty backgrounds, and particle effects. I'm definitely going to use fillp(). That sounds legit.
- animation for game over
- lives need pics
- the tileset changes themes. (there will be a cloud theme, hell/fire theme, and earth theme, and maybe a space theme, who knows)
- temporary power-ups (jump booster, run booster, extra life, countdown/don't have the screen chase you for a bit)
- tutorial level and being able to pick your level based on the highest one you've gotten to at the title screen.
- title screen tells the story, if no input has been pressed.
- prettyify some of the cloud structures.
Here is the story:
The Neo Jumper is trapped within his virtual reality. And what's worse, his virtual universe is crumbling. Running is the only hope of escape!
Controls:
Z: run
X: jump
Down Arrow: duck, speed down
I think this is going to be my most professional game I've made so far. I finally got into coroutines and some of the other deeper lua/pico8 concepts with this game so far. I'm finally going to play with particles for this game. I've written a song for the game also, but I haven't pico8-ified the song yet. Also, the initial inspiration for the gameplay was from the Google Dinosaur game, but now it is much different.
Let me know in a comment if you have any other good ideas for the game, or if you think you found a bug. :) Here is the github page for the game, I may move it to its own repo though later
View Older Posts
